WINMX Assorted Textfiles/Ebooks.tar/Text - Tech - Hacking - Hacking Unix - Part 4.txt

Text File | 2003-09-27 | 30KB | 776 lines

                          - HACKING UNIX -
                             PART FOUR:

                        Dealing with Firewalls
                 -----------------------------------

Edit started on 05/06/02 (MM-DD-YY)
Edit finished on 01/07/02 (MM-DD-YY)
By: detach (XT) - [DuHo] <http://www.duho.org>


&       ** This is a multi-part tutorial,
&       ** please check our website for other
&       ** parts:
&       ** http://www.duho.org/
&

INDEX:

0. - Forword
1. - Introduction
2. - Packet Filtering Firewalls
     2.1 - A pracical Example
3. - How does the packet filter work
     3.1 - Introduction
     3.2 - Stateless or Stateful
4. - Dealing with Firewalls
     4.1 - Introduction
     4.2 - 2D mapping of a firewall ruleset
     4.3 - 3D mapping of a firewall ruleset
5. - Using the gathered information
6. - Final words

0. Forword

This part explains what firewalls are, their purpose and how they work.
You will learn several techniques to detect a firewall and to discover
it's ruleset later on in this part. Understanding firewalls requires
understanding on networking and other things, certain references are
included to obtain that knowledge.
It's important to understand the role of firewalls in security and how
they work. This will be described and later on I'll focus on common
weaknesses.

1. - Introduction

Users on an internal network may need to access other networks in an
interconnected environment.
An organisation may want to restrict access to the Internet and will
especially want to restrict access from the untrusted Internet into the
internal network.
Firewalls are used to control network activity between the interconnected
networks.

Therefor an administrator creates a policy based on information about the
services that users need to access on the external network and the
services on the internal network requiring access from the outside of the
network.
It is also possible to restrict access into the internal network to a
certain part of the external network and vise-versa.

Using the policy, the ruleset is defined and applied to a firewall placed
between the two networks. A firewall is only effective if users are forced
to access the external network through the firewall (and vise-versa).
When a computer on the internal network has a modem it may be possible to
access the external network through a dial-up connection completely
bypassing the policy.

In this part you'll be introduced to the techniques hackers use to deal
with firewalls.

2. Packet Filtering Firewalls

In this chapter I discuss where and how firewalls are used. Chapter 3
generally explains how a firewall works and later on we'll focus on
``dealing with packet filters''.

Packet filters have a ruleset defined by the administrator. The packet
filter often operates at kernel-level and checks the header* on the packet
to see where it's heading. It than looks for these targets in it's ruleset
and decides it's fait. The packet can be discarded or accepted in
different ways, or it may trigger another action (for example to accept
the packet to pass through but to log the event).
{
    A header is like an envelope that sets the receiver (and sender).
    On network-packets we have multiple envelopes (headers) that
    together form the exact destination (it is layered).
}

In the case of the internet most packet filters operate on IP and TCP
level. IP specifies the host the packet is heading to, TCP identifies the
program that the packet is destined for.

2.1 A practical example.

We'll follow the proces the administrator of TotallySecure Inc. takes
for defining a packet filtering ruleset.

The first smart rule the administrator defines looks like this:

Source: Anywhere
Destination: Anywhere
Protocol: Any
Destination port: Any
Policy: DENY

The next thing the administrator does is to identify the exceptions to
this base rule.
{
    Note that there are also administrators that at first ACCEPT
    everything and then close some ports. This is the wrong way of
    thinking.
    Security can only be brought to the max. when you first disable
    everything and then enable some required features. And that goes
    for almost any element of a system.
}

An administrator may have a mailserver inside the organisations network.
The mail is delivered from and to the mailserver through the SMTP service
(for example sendmail or qmail). The administrator knows that the SMTP
service must be reachable from the internet to be able to receive mail.

So the administrator defines a new rule (exception on the first rule):

Source: External (Internet)
Destination: Internal mailhost
Protocol: TCP
Destination Port: 25 (SMTP)
Policy: ACCEPT.

Meaning that any packets from any address destined for the SMTP service
(TCP port 25) on the mailhost will be forwarded to the appropriate
direction.

The administrator grants all systems on the internet to deliver e-mail to
users' mailboxes. He does not have to define a rule for the internal
network. The users just need to connect to the mailserver, not to a
mailserver outside the internal network, so he'll only need to make an
exception for SMTP from the mailhost:

Source: Internal mailhost
Destination: External (Internet)
Protocol: TCP
Port: 25
Policy: ACCEPT.

The next thing the administrator wants is to allow users to receive their
mail from their mailbox on the mailserver using the POP3 protocol. The
administrator prefers to DENY access to the POP3 service from the internet
side. He asks several users if they *have to* retrieve their mail from
anywhere outside the organisation and finds out it's safe to block access
to this server from the internet-side for POP3 access.

He knows he won't need to change the firewall rules as this is no
exception to the first rule, although he just adds it to his note for
reference:

Source: External
Destination: Internal
Protocol: TCP
Destination Port: 110 (POP3)
Policy: DENY.

The administrator realises the simple fact that users need to use HTTP
access to the internet. He can simply ACCEPT outgoing HTTP traffic or
further restrict this access using a proxy server (in the last case he
only needs to allow outgoing HTTP from the proxy server).

He decides the last method is more secure. He installs a HTTP/HTTPS/FTP
proxy all-in-one solution. The proxy server runs on port 8080 and needs
only to be accessed from the internal network. So incoming traffic to port
8080 can safely be blocked. He sets up a LAN for the users behind the
proxy server. He adds a second network card to the mailserver so that the
mailserver is accessible on the LAN aswell as from the internet.

The first rule he adds is to allow outgoing FTP/HTTP/HTTPS from the
proxyserver:

Source: Internal proxy-server
Destination: External
Protocol: TCP
Destination Port: 21 (FTP), 80 (HTTP), 443 (HTTPS)
Policy: ACCEPT.

The administrator has now defined all rules he thinks are necessary. Next
the administrator goes on with adding spam- and virusblocking to his
mailserver etcetera.

3. How does the packet filter work.

3.1 Introduction

Network packets come into the network card which are then received at the
kernel of the operating system. If the operating system is setup as a
router it reads the packet and knows where to send the packet to. When a
firewall is installed it has the ability to read the packets and the
possibility to do something with it. It can drop (discard) the packet,
refuse (block, reject) the packet, accept the packet for further
processing or manipulate (mangle) the packet. All these decisions are
based on the information in the protocol's header which are matched
against filter rules.

I haven't explained the difference between dropping a packet and refusing
(blocking) a packet. A dropped packet is simply thrown away (discarded)
and the sender of that packet receives no notice. Rejecting (refusing) a
packet means discarding the packet and replying with a TCP RST packet,
the same response as it gets when you would try to open a connection to a
non-existing port. Ofcourse this rejecting only takes place when there are
specific flags set. To fully understand this you should read RFC 793 (TCP)
and RFC 791 (IP).

3.2 Stateless or Stateful.

A stateless firewall is very basic, it may simply check destination and
source address, destination port and source port and decide what to do
with it.

A stateful packet filter keeps track of a connection and has the ability
to do some meaningful packet manipulation. For example Network Address
Translation (NAT), where protocol information can be changed before it is
forwarded. This is used for example to make an internal host
(with a private-range IP-address) addressable from the internet.

Stateful packet filters can also have protocol helpers, which can be used
to make a protocol work through a firewall by manipulating the
application-level-data that the packet contains or anything more creative.

4. Dealing with Firewalls.

4.1 Introduction

Firewalls itself are not a target for our attacks. This may sound obvious
but this is exactly what is suggested when saying ``how can I break
security?'' or more explicitly ``how can I break through a firewall''. It
is not about breaking security it is about taking advantage of insecurity
elsewhere. More intelligent people do know this but still talk about
'breaking security' which is plain wrong. That's why I called this part
"Dealing with Firewalls" and not "Breaking Firewalls".
Although, there have been occasions where the firewall software itself
introduced new vulnerabilities. And some (older) firewalls may simply not
work well, but you'll see that. At first we will concentrate on a
different way to get around firewall restrictions anyway.

So we are going to *deal* with the firewalls and we will find out a
different way to defeat or bypass them.

4.2 2D discovery of a firewall ruleset

In this paragraph I will explain some techniques useful to map a firewalls
ruleset. This information is very useful for later stages of attack. For
example, you will already know how your backdoor needs to be configured,
or what kind of backdoor you will need. You may also need the information
for some kid of attacks on systems behind the firewall. We are not going
to focus on compromising the firewall initially because it is probably
secure enough, however, if it is vulnerable to remote attack we'll find
out anyway.

Now we are going to watch over the shoulder of a hacker named John that is
about to map the firewall ruleset of TotallySecure Inc's firewall. John
has just surfed into the website of TotallySecure and wants to know
if the company deserves the name it has. Note that this stage should be
part of the information gathering stage discussed in part 2.

John first sends a harmless ping addressed to the webserver:

# ping www.totallysecure.org
PING www.totallysecure.org (123.123.123.123): 56 octets data

--- www.totallysecure.org ping statistics ---
12 packets transmitted, 0 packets received, 100% packet loss
#

John knows there must be a some device in the way that drops the ICMP
(ping)  ECHO REQUEST packets, although he knows it doesn't have to be the
webserver itself.

Next, John wants to know if some ports are also being filtered (dropping
incoming connections on certain ports). Administrators often rather filter
ports and protocols instead of blocking them because the host appears to
be offline.
With the knowledge that a closed port needs to respond with an RST/ACK
packet when sending a SYN packet to it, he could see if the firewall is
filtering ports. He'll use the program 'hping' to discover this (found at
http://www.hping.org/):

# hping www.totallysecure.org -S -p 85
HPING www.totallysecure.org (eth0 123.123.123.123): S set, 40 headers + 0 data bytes

--- www.totallysecure.org hping statistic ---
10 packets transmitted, 0 packets received, 100% packet loss
round-trip min/avg/max = 0.0/0.0/0.0 ms
#

The -S switch indicates the SYN flag to be set and the -p flag specifies
the destination port. No response at all, it must be filtered too. Now, if
this firewall is intelligent in anyway, it will also drop any loose ACK
packets to that port. The normal behavior when sending a lonesome ACK
packet to a port is to receive an RST response. Now if the firewall is not
that smart it may only block SYN (for connection synchronization) packets
to that port. If we receive an RST packet after sending an ACK packet to
port 85 it indicates that it's a very basic firewall.

# hping www.totallysecure.org -A -p 85
HPING www.totallysecure.org (eth0 123.123.123.123): A set, 40 headers + 0 data bytes

--- www.totallysecure.org hping statistic ---
4 packets transmitted, 0 packets received, 100% packet loss
round-trip min/avg/max = 0.0/0.0/0.0 ms
#

No response at all, okay it's probably filtered properly. Note that the
ACK packets send to unfiltered ports (whether open or closed) always
return an RST packet. You can not determine if a port is open or closed.

Now, it is not important which port we used for this action (85), aslong
as we think it is probably not in use. It is this clue that may make us
think that the host has filtered all ports and made exceptions to specific
ports that require to be open (like the webserver). Atleast we may
conclude that because it is very unlikely port 85 is in use, as no
well-known service has this port assigned as yet.
How do I know this?

# grep 85 /etc/services
#

So if the admin is filtering a port that isn't in use, why wouldn't he
filter all ports that aren't in use? So John may assume now that the
administrators first rule was to DROP any connection on incoming ports,
atleast from the outside (the Internet). No ordinary backdoor could be
installed on the firewall without changing the ruleset if the firewall
works properly. Knowing that this packet filter also filters ACK packets,
we can later on scan all ports with ACK packets to make sure everything is
filtered.

There is another a way to see if the firewall is filtering properly, this
is done by testing it with fragmented packets. Fragmented packets are
normally used to send packets over networks with a low Maximum
Transmission Unit (MTU). Fragments can be this small that even the header
is split up into multiple packets. Some firewalls fail at blocking such
packets as they don't have the complete header, and they don't wait to
collect all fragments for reconstruction.

John performs a simple test against www.totallysecure.org with Fyodor's
Nmap tool:

# nmap -sS -p85 -f www.totallysecure.org -P0

Starting nmap V. 2.54BETA30 ( www.insecure.org/nmap/ )
Interesting ports on www.totallysecure.org (123.123.123.123):
Port       State       Service
85/tcp     filtered    unknown

Nmap run completed -- 1 IP address (1 host up) scanned in 36 seconds
#

He uses the -f switch to fragment the packet, -P0 to tell Nmap not to
check if the host is up (as PINGs don't pass through, Nmap will otherwise
think the host is down), -sS to do a SYN scan. As it turned out, Nmap
split the packet in 6 fragments, as seen with a header sniffer. We could
do this scan with ACK packets as well.

What if we send packets with no flags at all? A so-called NULL scan should
return RST packets if the port is closed, and no result if the port is
open. It is this why this scan is not really reliable, because this type
of scan indicates a port being open if it is filtered (dropped).

The problem is that Windows systems return an RST packet even if the port
is open (against the specification) and so this scan is not usable to scan
Windows systems. But it is still useful against Windows systems for
testing the firewall ruleset, the same way as using ACK packets.

For UNIX systems it is useful if we have to deal with a basic firewall
that only blocks SYN packets. Because then we already know what port the
firewall is supposed to filter. Then we use a ACK scan to determine if the
firewall is a basic one. Then we use the NULL scan to see if the port
being filtered is actually open or not. For example:

Step 1:

# nmap -sS -p110 www.totallysecure.org -P0

Starting nmap V. 2.54BETA30 ( www.insecure.org/nmap/ )
Interesting ports on www.totallysecure.org (123.123.123.123):
Port       State       Service
110/tcp     filtered    pop3

Nmap run completed -- 1 IP address (1 host up) scanned in 1 second
#

Step 2:

# nmap -sA -p110 www.totallysecure.org -P0

Starting nmap V. 2.54BETA30 ( www.insecure.org/nmap/ )
The 1 scanned port on www.totallysecure.org (123.123.123.123) is: UNfiltered

Nmap run completed -- 1 IP address (1 host up) scanned in 1 second
#

Step 3:

# nmap -sN -p80 www.totallysecure.org -P0

Starting nmap V. 2.54BETA30 ( www.insecure.org/nmap/ )
Interesting ports on www.totallysecure.org (123.123.123.123):
Port       State       Service
110/tcp     open        pop3


Nmap run completed -- 1 IP address (1 host up) scanned in 12 seconds
#

See, in case the admin used a basic packetfilter, we just found out the
POP3 service is open but filtered. If that didn't succeed, we should also
try in conjunction with the fragmentation option (-f). This knowledge may
introduce the idea that the port must somehow be in use, maybe only to
serve internal netwerk users. Otherwise the administrators is to lazy to
turn off the POP3 service.

Using the above techniques, John has a basic idea of the type of firewall
being used. In this case John concludes www.totallysecure.org is secured
by one or more firewalls that drop incoming connections on filtered ports.
The firewall is not vulnerable to fragmented packets nor is it a basic
firewall that chases after SYN packets only. John continues finishing his
2D view of the webserver by doing the SYN, ACK and NULL scans against all
the 65535 possible ports during the period of about month (not not raise
too much suspicion).

The 2D map results in:

Protocol ICMP: dropped
All TCP ports dropped except port 80.

John has both gathered information on the open/closed ports and the
firewall configuration. He did it in a non-intrusive and stealthy manner.

The next questions John wants to investigate are:

- is the firewall on the same site as the webserver?
- howmany firewalls are there?
- where are the firewalls located?

This is what I call a 3D mapping. A 2D mapping maps all obstacles in the
way to a target, no knowledge of distance are known. In a 3D map John
knows on which systems services are available and where packets are
filtered.

4.3 3D mapping of a firewall ruleset

What I call -3D mappings- are a series of probes and information gathering
methods that result a visual map. It is used to determine which sites
provide which services while figuring out why it is setup that way along
with the location of where packets are filtered. Combining this
information with the 2D mapping results a detailed report of the physical
configuration as well the logical configuration and why it works that way.

Again, we'll follow John the hacker in his info gathering stage with
TotallySecure Inc. being his target.

In the 2D mapping stage John learned that (probably all) ICMP type packets
don't pass through. In this stage John wants to know which device along
the way is blocking it. Now how does he do that? He's about to use a
series of traceroute-type probes to determine the site that's blocking
these packets. First things firts, John writes a quick shell script for
determining the location of the ICMP filter:

--- trace_icmp.sh ---
#!/bin/sh
# determine ICMP filter location

cnt=1
while [ $1 ] ; do
   echo hop \#$cnt:
   hping -1 -c 1 -t $cnt $1
   let cnt=cnt+1
   sleep 1
done
--- end ---

John is now able to determine where the packet is filtered.

--- determine ip address ---

# nslookup www.totallysecure.org
Server:         127.0.0.1
Address:        127.0.0.1#53

Name:   www.totallysecure.org
Address: 123.123.123.123

#

--- end ---

John first looks up the ip adress so hping won't have to look it up itself
everytime.

--- trace icmp filter ---

bash-2.05a# ./trace_icmp.sh 123.123.123.123
hop #1:
HPING 123.123.123.123 (eth0 123.123.123.123): icmp mode set, 28 headers + 0 data bytes
TTL 0 during transit from ip=100.100.100.1 name=gateway.attackers.org

--- 123.123.123.123 hping statistic ---
1 packets tramitted, 0 packets received, 100% packet loss
round-trip min/avg/max = 0.0/0.0/0.0 ms
hop #2:
HPING 123.123.123.123 (eth0 123.123.123.123): icmp mode set, 28 headers + 0 data bytes
TTL 0 during transit from ip=100.100.1.1 name=gateway.hackerisp.org

--- 123.123.123.123 hping statistic ---
1 packets tramitted, 0 packets received, 100% packet loss
round-trip min/avg/max = 0.0/0.0/0.0 ms

....
....
....
....

hop #18:
HPING 123.123.123.123 (eth0 123.123.123.123): icmp mode set, 28 headers + 0 data bytes

--- 123.123.123.123 hping statistic ---
1 packets tramitted, 0 packets received, 100% packet loss
round-trip min/avg/max = 0.0/0.0/0.0 ms
hop #19:
HPING 123.123.123.123 (eth0 123.123.123.123): icmp mode set, 28 headers + 0 data bytes
ICMP Packet filtered from ip=123.123.1.1 name=UNKNOWN

--- end ---

Now this makes sense, the filter that filtered the ping packets was not
the one on the webserver... but a gateway at hop #19.
Next John wants to know on which hop the webserver is. How does he figure
that out? Simple:

--- trace_tcp.sh ---
#!/bin/sh

cnt=1
while [ $1 ] ; do
   echo hop \#$cnt:
   hping -S -p $2 -c 1 -t $cnt $1
   let cnt=cnt+1
   sleep 1
done

--- end ---

How could you use this script? Well, just pick a port that you know is
open, John will use port 80. Then this script can be used to determine the
number of hops until the port 80 has been reached.

Let's see John in the act:

--- trace count hops to destination ---

bash-2.05a# ./trace_tcp.sh 123.123.123.123 80
hop #1:
HPING 123.123.123.123 (eth0 123.123.123.123): S set, 40 headers + 0 data bytes
TTL 0 during transit from ip=100.100.100.1
--- 123.123.123.123 hping statistic ---
1 packets tramitted, 0 packets received, 100% packet loss
round-trip min/avg/max = 0.0/0.0/0.0 ms

....
....
....
....

hop #21:
HPING 123.123.123.123 (eth0 123.123.123.123): S set, 40 headers + 0 data bytes
len=46 ip=123.123.123.123 flags=SA DF seq=0 ttl=63 id=0 win=5840 rtt=575.6 ms

--- end ---

John learned that there is a packet filter filtering ICMP packets at hop
19, and the webserver is at hop 21. That's interesting, so the second
gateway from the webserver is filtering ICMP packets. It may also be
possible that the first gateway before the webserver is also filtering
ICMP, but that doesn't matter.

Next John wants to know if all ports are firewalled by that firewall. So
he does another probe:

---
# hping -A -p 85 -c 1 -t 19 www.totallysecure.org
HPING www.totallysecure.org (eth0 123.123.123.123): A set, 40 headers + 0 data bytes
TTL 0 during transit from ip=123.123.123.1 name=UNKNOWN

--- www.totallysecure.org hping statistic ---
1 packets tramitted, 0 packets received, 100% packet loss
round-trip min/avg/max = 0.0/0.0/0.0 ms
#
--- end ---

Nope, we receive an ICMP port unreachable atleast port 85 is not filtered
at the same address as ICMP is filtered.

Now there are only two options: the packet is filtered at the gateway just
before the webserver, or on the webserver itself:

--- determining where port 85 is filtered  ---

# hping -A -p 85 -c 1 -t 20 www.totallysecure.org
HPING www.totallysecure.org (eth0 123.123.123.123): A set, 40 headers + 0 data bytes

--- www.totallysecure.org hping statistic ---
1 packets tramitted, 0 packets received, 100% packet loss
round-trip min/avg/max = 0.0/0.0/0.0 ms
#

--- end ---

Port 85 is filtered at the gateway before the webserver.
Let's see which address this gateway has:

--- resolving gateway address ---

# hping -S -p 80 -c 1 -t 20 www.totallysecure.org
HPING www.totallysecure.org (eth0 123.123.123.123): S set, 40 headers + 0 data bytes
TTL 0 during transit from ip=123.123.123.1 name=UNKNOWN

--- www.totallysecure.org hping statistic ---
1 packets tramitted, 0 packets received, 100% packet loss
round-trip min/avg/max = 0.0/0.0/0.0 ms

#

--- end ---

As we already knew, it is 123.123.123.1 that is firewalling this port.

John continues his probing work and finds out the following:

123.123.1.1 (hop 19) filters: ICMP, TCP port 31337
123.123.123.1 (hop 20) filters: All TCP ports except port 80

John considers that TotallySecure Inc. owns the whole 123.123.123.0
segment, and that 123.123.123.1 is their own firewall. 123.123.1.1 is
probably the gateway of their ISP (Internet Service Provider).

John draws the following 3D map:

  *******************
  # 123.123.123.123 #
  *******************
  _________|_____________|_____________|_____________|_____________|__
                           |
                   *****************
                   # 123.123.123.1 #
                   *****************
  ___________|_____________|_____________|_____________|______________
                                   |
                            ***************
                            # 123.123.1.1 #
                            ***************
                                   |
                                  ***
                               ***   ***
                           **** INTERNET ****
                               ***   ***
                                  ***

John believes that TotallySecure Inc.'s network must have a mailserver
that's in the 123.123.123.0 segment. So how could he verify this? Simple:

--- lookup mailserver ---

# host -t mx totallysecure.org
totallysecure.org mail is handled by 100 relay1.bizznet.com.
totallysecure.org mail is handled by 50 mail.totallysecure.org.
#

--- end ---

Aha, two mail handlers, one appears to be the one of the ISP, and one
probably operated by totallysecure themselves.

# host relay1.bizznet.com
relay1.bizznet.com has address 123.123.1.65
# host mail.totallysecure.org
mail.totallysecure has address 123.123.123.80
#

John draws the new 3D map:

  *******************          ******************
  # 123.123.123.123 #          # 123.123.123.80 #
  *******************          ******************
  _________|_____________|_____________|_____________|_____________|__
                           |
                   *****************           ****************
                   # 123.123.123.1 #           # 123.123.1.65 #
                   *****************           ****************
  ___________|_____________|_____________|_____________|______________
                                   |
                            ***************
                            # 123.123.1.1 #
                            ***************
                                   |
                                  ***
                               ***   ***
                           **** INTERNET ****
                               ***   ***
                                  ***

The firewall only passes port 80 traffic if the destination is the
webserver, and port 25 only if the destination is the mailserver. Very
smart! John continues to fill in the above geographical map with this
information and the gathered information from the 2D mapping.

Note that the 3D mapping thing includes a technique called 'Firewalking'
discovered by Mike D. Schiffman and David E. Goldsmith. They also wrote a
program called 'Firewalk' to bring this technique to the public. You can
more information on it here:
http://www.packetfactory.net/Projects/firewalk/

John continues to scan all 255 possible hosts behind the firewall, but
comes up with no new results.

5. Using the gathered information

John knows that this packet filter is set up fairly restricted:

- John sees no possibity to compromise the firewall itself
- John can't use no classic inbound backdoor when exploiting weaknesses in
  a system behind the firewall
- No ICMP channel available

In later stages when John is able to compromise one of the servers behind
the firewall (either through active attack on the mailserver or attack on
the webserver), he won't be able to use a classical inbound backdoor.

To play it safe, John needs to trojan or patch either the mailserver
software or the webserver. Another way is to use a reversely connecting
backdoor, that connects to a local server on your system instead of the
reverse. But that would not be very smart, as the backdoor would require
to know the address of his attacking host, also outgoing traffic may be
restricted too.

A backdoor on the webserver could be a server-side script that can execute
things through a webinterface. Or a special module, or a real patch of the
webserver which can be controlled through specially crafted requests.
Otherwise, the mailserver needs to be patched.

He could also create an automated program which works like a worm that
compromises the whole network behind the firewall and leaks information
back to John, which would require John to guess what vulnerabilities
could be exploited behind the firewall.

6. Final words

In this part you learned how to gain important information about the
target's network set-up as well as understanding how packet filters are
configured and how they sometimes can be bypassed.

These methods should be part of the information gathering stage discussed
in part 2, though there was somuch to tell that it deserves a seperate
part.

Please look out for new 'Hacking Unix' parts during the next couple of
months.

detach (XT) [DuHo] 2002

Visit http://www.duho.org/ for updates or new parts of this tutorial every
now and then.

-EOF-
Size: 32768 bytes
chars: 29428
words: 4556
Lines: 767